home *** CD-ROM | disk | FTP | other *** search
- Path: solon.com!not-for-mail
- From: danpop@mail.cern.ch (Dan Pop)
- Newsgroups: comp.std.c,comp.lang.c.moderated
- Subject: Re: Integral promotion.
- Date: 15 Feb 1996 09:03:18 -0600
- Organization: CERN European Lab for Particle Physics
- Sender: clc@solutions.solon.com
- Approved: clc@solutions.solon.com
- Message-ID: <4fvhvm$e8s@solutions.solon.com>
- References: <4fstj7$2l6@solutions.solon.com> <4fu835$9de@solutions.solon.com>
- NNTP-Posting-Host: solutions.solon.com
- X-Newsreader: NN version 6.5.0 #7 (NOV)
-
- >The final step is to convert the sum back to type `short'. Here
- >things get a little fuzzy; comp.std.c has had arguments as to what
- >happens if the sum is `int', `int' is wider than `short', and the
- >sum is not representable as a `short'. The Standard distinguishes
- >between `implicit' and `explicit' conversions, and this is an
- >`implicit' conversion (casts are the usual, perhaps the only, way
- >to write explicit conversions). Some have argued that an explicit
- >conversion should never cause an overflow, but there seems to be
- >no wording in the standard to justify this position. There appears
- >to be agreement that implicit conversion might overflow. The
- >behavior on overflow would be undefined.
-
- This is a very common misconception. From ANSI classic:
-
- 3.2 CONVERSIONS
-
- Several operators convert operand values from one type to another
- automatically. This section specifies the result required from such
- an implicit conversion, as well as those that result from a cast
- ^^^^^^^^^^^^^^^^^^^^^^
- operation (an explicit conversion).
- ...
- 3.2.1.2 Signed and unsigned integers
-
- When an integer is demoted to a signed integer with smaller size, or an
- unsigned integer is converted to its corresponding signed integer, if
- the value cannot be represented the result is implementation-defined.
-
- Whoever agreed that the implicit conversion between integer types could
- cause undefined behaviour was in open conflict with the text of the
- standard (unless the standard was revised on this particular topic).
-
- Dan
- --
- Dan Pop
- CERN, CN Division
- Email: danpop@mail.cern.ch
- Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
-